Internet Surfer 2.0

home *** CD-ROM | disk | FTP | other *** search

/ Internet Surfer 2.0 / Internet Surfer 2.0 (Wayzata Technology) (1996).iso / pc / text / mac / faqs.026 < prev next >

Wrap

Text File | 1996-02-12 | 28.6 KB | 633 lines

Frequently Asked Questions (FAQS);faqs.026 A16: Using XDV.COM, DESQview Classic or DESQview-386 can load most of itself into upper and high memory so conventional memory is preserved. However, loading many TSRs or DOS high (see Q22) will reduce the amount of DESQview that can be loaded high (i.e. in the XMA - the first 64K of extended memory). DVX386 automatically loads itself into high memory. DESQview also sets aside a portion of conventional memory and calls it ``Common Memory''. The amount that DESQview allocates can be decreased in DVSETUP, but the minimum is about 14K. Certain programs such as DVSI (a set of shareware utilities by Daniel Bodoh) require the amount of Common Memory to be larger than the minimum. A large Open Window menu or many ``shared programs'' will also increase the required amount of Common Memory. Each window has an area of memory called ``System Memory''. The amount of System Memory available to a program is controlled by three separate entries on the Change A Program screen. First, since DESQview stores the window image in System Memory, decreasing the number of text pages and maximum window size decreases System Memory usage. Second, since most programs do not explicitly use System Memory, the System Memory field can be set to 1K or 0K. The pool of System Memory only reduces the maximum window memory for that particular window, and does not affect the other windows. You can see this using the Memory Status program. It will report, say, 592K of conventional memory available, but part of that is used for System Memory so the actual amount available is less. QW:161:WINSIZE.TEC, QW:252:MAXWINDO.TEC --------------------------------------------------------------------------- Q17: What are some programs that are incompatible with DESQview? A17: [Please forward any other known incompatibilities to the editor of this FAQ list (see above).] Any ``386 Control Program'' that is not VCPI compliant (see Q15). BitFax Borland C++ 3.0 Borland has a patch on Compuserve and the Borland BBS. This patch is also available on SIMTEL20 as DPMIFI.ZIP in PD1:<MSDOS.CPLUSPLUS> (see Q7). Colorado Memory Systems, Inc.'s TAPE.EXE Incapable of finding a tape drive piggybacked to a floppy adapter when run in a DVC window. It does not crash the system, but backups are not possible when inside DESQview. Colorado will be fixing this in the future. Under DVX, it can find the tape drive. ConFormat Diagnostic programs that try to go into protected mode to tested extended memory will fail under QEMM. These include QAPLUS and RAMTEST. Diagnostic programs should be run from a boot floppy. DJGPP/DJGPP-compiled programs Finally, DJGPP 1.09 available via anonymous FTP from BARNACLE.ERC.CLARKSON.EDU [128.152.28.12] in /pub/msdos/djgpp, works with DESQview/X (and probably DESQview, too). For those of you who don't know, DJGPP is a full 32-bit C/C++ compiler for DOS with a DOS extender which allows you to use *all* your 386 memory and your disk as memory. DJGPP 1.09 can compile X windows programs written for DESQview/X with the companion X libraries (see Q8). DR DOS 6.0 history feature DR DOS works great with DESQview, except for the history feature. DVFormat by SLR Systems Has problems with DESQview/X which Quarterdeck are trying to fix. Games that use digitized sound without extra sound hardware. Digitized sound requires that the timer interrupt be sped up to 8000 or more interrupts per second, which DESQview can't deal with. The only workaround is to turn off the sound or buy extra sound hardware. Micronics rev 1.10.05 and 1.10.06 motherboards with Phoenix BIOS Incompatible with QEMM-386. The first rev that worked again with QEMM was 1.10.10. Contact Phoenix for a BIOS upgrade. Mountain FileSafe 4000 Tape Backup Software Microsoft C/C++ 7.00 MSC requires a DPMI host which until now QEMM did not provide. You can now use QDPMI to allow QEMM to become a DPMI host. MS-Kermit 3.11 Try setting Optimize Communications in DVSETUP to No. If that doesn't work, use the Kermit SET COM command to set the exact interrupt request and I/O port used. The problem will be fixed in 3.12. QA Plus (see above note on Diagnostic programs) RAMTEST (see above note on Diagnostic programs) Soundblaster Games that use Soundblaster require ``Share CPU'' be set to N or the music will be choppy. Some games do work OK, though. Speed (LandMark Tests 2.00) Crashes DESQview Windows Enhanced Mode (see Q11) --------------------------------------------------------------------------- Q18: I'm having a problem {configuring DESQview, running a program, etc.}. How do I fix it? A18: First of all, take a look at the manual. This may seem obvious, but you'd be surprised at the number of people that post problems which they could have solved themselves by glancing at the manual. If you still can't figure it out, post a complete description of your problem. Don't just say, for example, ``foo.exe doesn't run''. Be specific. Post the Change A Program screens, or portions of AUTOEXEC.BAT or CONFIG.SYS if relevant. But use some restraint. Don't post 18 pages of system configuration information just because you can't get foo.exe to print ``Hello, world''. --------------------------------------------------------------------------- Q19: How can I contact Quarterdeck? A19: Quarterdeck Office Systems 150 Pico Boulevard Santa Monica, CA, USA 90405 Technical Support: Phone: (310) 392-9701 Fax: (310) 399-3802 Sales: Phone: (310) 392-9851 Fax: (310) 399-3802 Customer Service or Orders: Phone: (800) 354-3222 QOS BBS: (310) 314-3227 (24 hours/day, 1200-9600, HSD 14.4k and V32bis, 8 bits, No parity) E-mail (for Tech Support): Internet/Usenet/UUCP: support@qdeck.com Quarterdeck BBS: Sysop CompuServe: 76004,2310 BIX: QOS.REP2 MCI Mail: QUARTERDECK Smartnet: DESQview Conference - Quarterdeck USA Public Message forums for Quarterdeck Tech support: QOS BBS: <T>echnical Support Message System CompuServe: ``GO QUARTERDECK'' BIX: ``JOIN DESQVIEW'' SmartNet: DESQview Conference FidoNet: DESQview Echo (currently no QOS support online) RelayNet: DESQVIEW - Quarterdeck USA or Quarterdeck Canada ILINK: Multitaskers Usenet: comp.os.msdos.desqview - QOS techs are active Ireland ------- European Headquarters Quarterdeck International Ltd. B.I.M. House, Crofton Terrace Dun Laoghaire, Co. Dublin, Ireland Phone: +353 1 2844-144 Fax: +353 1 2844-380 BBS: +353 1 2844-381 QFAX: +353 1 2844-383 Product Information/Registration Cards: Phone: +353 1 2841-444 Fax: +353 1 2844-380 United Kingdom -------------- Quarterdeck Office Systems UK Ltd. Widford Hall, Widford Hall Lane, Chelmsford, Essex, CM2 8TD, United Kingdom Technical Support Phone: + 4471 973-0663 Fax: + 4471 973-0664 BBS: + 4471 973-0661 QFAX + 4471 973-0665 Product Information/Upgrade/Registration Cards: Phone: + 44 245 496699 Fax: + 44 245 495284 BBS: + 44 245 263898 Canada ------ Quarterdeck Office Systems Canada, Inc. 70 York St., Suite 1220 Toronto, Ontario M5J 1S9 Phone: +1 (416) 360-5758 Fax: +1 (416) 360-4885 Upgrades: +1 (800) 268-5181 Germany ------- Quarterdeck Office Systems GmbH Willstaetter Strasse 15 D-4000 Duesseldorf 11 Germany Technical support: Phone: +49 211 / 59790-40 Fax: +49 211 / 59790-60 QFAX +49 211 / 59790-65 Product info, upgrades: Phone: +49 211 / 59790-0 Fax: +49 211 / 594126 France ------ Quarterdeck Office Systems S.A.R.L., 4, Rue de General Lanrezac, 75017 Paris, France. Technical Support Phone: Int + 33 144-09-03-40 Fax: + 33 144-09-00-69 BBS: + 33 144-09-01-07 QFAX: + 33 144-09-00-81 Product Information/Upgrade/Registration Cards Phone: + 33 144-09-03-91 Fax: + 33 144-09-03-47 Cyprus / Eastern Mediterranean ------------------------------ Quarterdeck Office Systems Middle East Ltd. 1 Souliou Street, Suite 103, Strovolos, Nicosia, Cyprus. Product Information/Upgrade/Registration Cards/Support Phone: + 357 2311-630 Fax: + 357 2311-560 Spain ----- Quarterdeck Office Systems S.A., Gran Via de les Courts, Catlanes, 617, 10-3A 08007 Barcelona, Spain. Product Information/Upgrade/Registration Cards/Support Phone: + 343-412-29-45 Phone: + 343-412-44-41 --------------------------------------------------------------------------- Q20: What books are available on DESQview? A20: ``DESQview - A Guide to Programming the DESQview Multitasking Environment'', by Stephen R. Davis, M&T Books Publishing, 501 Galveston Drive, Redwood City, CA 94063. 346 pages. 1st Edition, 1989. [This is a review from Quarterdeck. I've heard from others that this books is really not that good and doesn't have many examples. Look it over well before you spend any money.] A very good source on programming in C using the DESQview API. This is a tutorial book with lots of examples. Would be useful to programmers who find the QOS API manuals somewhat daunting. All examples are in C, however there is lots of general information which would be useful for developers programming in any language. Available direct from M&T and bookstores which specialize in technical works. Can be ordered from Quarterdeck order line at (310) 392-9851 for $24.95 ($39.95 with disk - 5 1/4 inch only). ``The Official DESQview Sourcebook'', Larry Joel Goldstein, Bantam Computer Books, 666 Fifth Ave., New York, NY 10103. 351 pages. 1st edition - Sept. '89, price $22.95 ($27.95 Canada). A comprehensive guide to the use of DESQview, QEMM and the DESQview Companions. Contains a section on the DESQview API that may serve as an introduction, but this is not a programmer's book. A useful adjunct to the Quarterdeck manuals when you want similar information from another view. ``DOS Beyond 640K'', Second Ed. James Forney, Windcrest Books, Division of TAB Books Inc., Blue Ridge Summit, PA 17294-0850. 1989. 235 ISBN 0-8306-9717-9, ISBN 0-8306-3744-3 pbk. pages. Price $19.95. Not a DESQview/QEMM book specifically, but an excellent book on the subject of memory, with many references to DESQview and QEMM. Highly recommended to users who really want to understand the use of memory in their PCs. ``The Best Book of DESQview'', Jack Nimersheim, Howard W. Sams & Company, 11711 North College, Suite 141, Carmel, IN 46032. 1st Edition 1990, 396 pages. Price $24.95 A user-friendly guide to DESQview, the Companions, QEMM and Manifest. Contains many tips and a good discussion of the DESQview Learn feature. ``Mastering DESQview'', Jonathan Kamin, Scott, Foresman IBM Computer Books, 1900 E. Lake Avenue, Glenview, IL 60025. 1st Edition 1990, 387 pages. Price $24.95. A comprehensive guide to the use of DESQview, with emphasis on hints and techniques which enhance the use of DESQview. Special emphasis on creative use of DESQview's Learn (macro) facility. ``Extending DOS,'' Ray Duncan, Charles Petzold, M. Steven Baker, Andrew Schulman, Stephen R. Davis, Ross P. Nelson, Robert Moote, Addison-Wesley Publishing Co., Second edition, 1992. An excellent work on DOS memory usage and some of the options for extending DOS. For advanced users and programmers. Quite a bit of example source code included. Covers IBM PC Programming Architecture, EMS, XMS, DOS Extenders, Windows, DESQview, VCPI, DPMI and Multitasking. ``DESQview Instant Reference,'' Paul J. Perry, 1991, Sybex, 166 Pages. Price $9.95 This is a basic, short reference guide to DESQview, QEMM-386, and Manifest. It covers up to versions 2.3 of DESQview and version 5.1 of QEMM-386. It describes the use of all the DESQview functions, QEMM-386 switches, and switches for LOADHI, QEMM.COM, VIDRAM. All the information provided is in the Quarterdeck manuals. ``Understanding DESQview,'' Richard Altman, 1991, Sybex, 307 pages. Price $24.95 ``DESQview Unleashed'', Dave Williams, SAMS. Coming in August 1992. Will include part of this FAQ! ``Memory Management for All of Us'', by John M. Goodman, Ph.D. SAMS, 1992. ISBN 0-672-27366-7. Price $29.95. Discusses virtually all aspects of PC memory and memory management, including how DESQview uses memory. ``XView Programming Manual,'' Dan Heller, etal., O'Reilly & Assoc. 586 pages. Price: $34.95 ``X Window System Programming,'' Naba Barkakati, 1991, Howard W. Sams & Co. 600 pages. Price: $29.95 Good introduction to X programming, with many helpful example programs. Covers xlib, xt Intrinsics, and some discussion of OSF/Motif widgets is provided. ``Introduction to the X Window System,'' O. Jones, 1989, P-H. Price: $38.00 ``The X Window System in a Nutshell'', 1990, O'Reilly & Assoc. Price: $24.95 [If you know of any more, please let me know] QW:132:BOOKS.TEC --------------------------------------------------------------------------- Q21: What are the command-line switches for DESQview/QEMM/QRAM? A21: The file QOSSWIT3.ZIP from SIMTEL20 (see Q7) in the PD1:<MSDOS.INFO> directory contains a list of the documented and undocumented switches for Quarterdeck's products. QW:178:ALL-HELP.TEC --------------------------------------------------------------------------- Q22: How can I configure DESQview for maximum window memory? A22: The answer to this question is very system dependent. However, you should use QEMM rather than EMM386 and HIMEM.SYS (on a 386), because QEMM is smaller and will provide the same services. Also, without QEMM screen virtualization is not possible (see Q2). Loading DOS high will not necessarily help, because that reduces the amount of DESQview kernel that can be loaded high (see Q16). When you test using DOS=HIGH, make sure you add I=0800-0FFF to QEMM line. This will allow QEMM to map the area vacated by DOS, so you may see a gain in window size. You almost have to be using stealth to see a net gain. Also, if you don't need graphics, you can use the VREMS parameter on the QEMM line, and add VIDRAM ON to the DV.BAT file. This will give you about 64k more for each window. DV.BAT should actually have a VIDRAM ON before calling DV, and VIDRAM OFF after DV. Experiment. Use Manifest to judge the results. If your high memory is very fragmented (i.e. many small contiguous blocks rather than a few large blocks), keeping DOS and TSRs low and putting DESQview high might work better. Do not set up your path and environment variables until all the TSRs have been loaded. A copy of the environment is made for every TSR, and if the TSR does not give this area of memory back to DOS, it is wasted. QEMM's STEALTH feature should be used if it is compatible with your machine. There are three different STEALTH modes: ST:F - Frame stealth. Compatible with many machines, but offers the least amount of memory gain. Also known as ``Female Stealth''. ST:M - Mapping stealth. It offers significantly more memory gain but will not work on all machines. Also known as ``Male Stealth''. ST:P - Protected mode stealth. Undocumented and unsupported by Quarterdeck, because it has many incompatibilities. If you can get it to work on your machine, you could get an additional 25K or so over ST:M. You cannot run any other protected mode programs with ST:P (the DVX stuff seems to work, though). Here's a neat trick to save memory under DVX. This is from David Granz. How to Maximize your memory space for programs under DVX --------------------------------------------------------- In order to use DV/X on a TCP/IP network, the FTP software TCP/IP drivers must be loaded. Unfortunately, these TSRs can take up over 100K of precious DOS memory space. In addition a mouse driver is needed (another 12-16K of memory used up). And then, DV/X itself chews up a significant amount of DOS memory. Even with the new QEMM stealth features that allow most of the upper memory space to be used to LOADHI these TSRs, the memory actually left for a program (or DOS window) under DV/X can end up being quite small. In my particular setup, the best I was able to get was a 320K DOS window. After much experimenting and some suggestions from Quarterdeck, I have come up with the following procedures that allow you get very close to a full 640K of program space in a DOS window (somewhat less if you don't have a 8514 video card). Note that although this method seems to work fine (for me at least), it is not in anyway a supported method. Please DO NOT call Quarterdeck for help with this setup, they are not supporting this technique at this time. If you have problems with things crashing, put things back the way they were before, and see if the problems go away. Then, if the crash still occurs, you have a valid reason to call Quarterdeck. Before doing any of the following modifications, make a safe copy of \DVX\STARTUP.DVP and \DVX\DVPS\PCTCP.DVP. These copies can be used to restore the system in case you have problems. Step 1, Saving the space occupied by the MOUSE driver: Create a file called \DVX\SERVER.BAT that contains the following lines: MOUSE (or whatever is needed to run your mouse) SERVER Then with the DVPMAN program (under DV/X), modify the file \DVX\STARTUP.DVP. Change the reference to SERVER.EXE to SERVER.BAT. Also increase the memory size by enough to cover the added size of the mouse driver (about 30k should be plenty). Modify your CONFIG.SYS and/or AUTOEXEC.BAT to not load the mouse driver when you boot your computer. Restart the computer, and then DV/X... The mouse driver should now load in the process space of the server. A 'mem/c' command in a DOS window, should show more memory available and no copy of the mouse driver. Step 2, Saving the space occupied by the TCP drivers: In a manner similar to the above mouse modifications, you need to create a batch file: \DVX\NETWORK\NETWORK.BAT. This batch file should contain all the drivers and network programs needed to support TCP/IP. The last step should be to run the 'nsftp' program. For example, my NETWORK.BAT looks like this: c:\dvx\device c:\ftp\ifcust.sys c:\dvx\device c:\ftp\ipcust.sys c:\ncsa\drivers\wd8003e -w 0x62 7 0x280 0xD000 c:\ftp\ethdrv -t 20 -p 26 -u 2 nsftp Using DVPMAN, modify the \DVX\DVPS\PCTCP.DVP parameters to run NETWORK.BAT rather than NSFTP.EXE. You should add enough memory allocation to allow for the extra memory of the network drivers. In my case a 350K allocation seems to work fine but you may need more. Remove all the network drivers and TSRs from your CONFIG.SYS and AUTOEXEC.BAT, and reboot DOS and DV/X. If all goes correctly, the DOS windows under DV/X should now contain none of the network drivers. With this arrangement I am able to get about 550K available in the DOS window. The only limitation of this arrangement, is that only Quarterdeck supplied network programs (telnet, ftp, etc) will work. This is because the network drivers are running in a different address space than the DOS windows. The normal FTP software's and Packet driver's access interrupts are not available in any process other than the PCTCP process. Step 3, Getting even more space: If you have a 8514 type video card (I have a ATI Graphics Ultra), you can get even more space for DOS programs. As an added advantage, the video performance is much better with this card (1024x768x256). Add the 'VREMS' parameter to your QEMM386.SYS line in CONFIG.SYS. This will allow the \QEMM\VIDRAM program to steal the address space at A0000-AFFFF for DOS use. Before starting DV/X, do a "\QEMM\VIDRAM ON" command. Just ignore the message that DV/X cannot find a graphics card. DV/X will run just fine without this video ram area. The DOS window will be 64K bigger. The only limitation of this, is that graphic programs (ie ones that take over the entire screen) must not be run. Text programs and programs that use X windows calls will work just fine. QW:161:WINSIZE.TEC, QW:252:MAXWINDO.TEC --------------------------------------------------------------------------- Q23: What is NOFF.SHP {NOFF.SHR}? A23: NOFF.SHR is an older version of NOFF.SHP. So what's NOFF.SHP? DESQview is the child of an older IBM program called TopView. Because Quarterdeck wanted DESQview to run all the old TopView programs, they made DESQview compatible to TopView, in much the same way you can run programs written for DOS 3.3 in DOS 4.0. If a program writes directly to the video memory, TopView (and DESQview) cannot run it in a small window. So IBM allowed programs to be TopView- aware (similar to DESQview-aware (see Q3)) by giving them ``virtual'' video memory on request. This memory looks like video memory, but characters written into it do not get displayed on the screen. Since DESQview is a much smarter program that TopView ever was, DESQview can automatically update the window from the virtual video memory. But TopView did not have that ability. The TopView-aware program had to make another call which would manually update the window from the video memory. Quarterdeck wanted to make DESQview look as much like TopView as possible, so they decided that if a TopView-aware program makes this call to update the window, then the automatic updating of DESQview would be turned off. DESQview can do a better job of updating the window from the virtual video buffer than *some* programs. So the purpose of NOFF.SHP is to capture the TopView update call before it gets to DESQview and not let DESQview see the call. That way, DESQview never turns off the automatic updating, and your window output is less jerky. Whether or not you should use NOFF.SHP depends on how the TopView-aware program updates its screen. If it changes only small parts of the screen at a time but requests that the entire screen be updated, use NOFF.SHP. But if the program tells TopView (DESQview) exactly which part of the screen changed, output may look smoother without NOFF.SHP because an automatic update doesn't take place until the end of each program's time slice (see Q9). Although NOFF.SHP is included in the Quarterdeck-supplied DVP for Wordperfect, it is not required if you are using a 386 or better and you turn on text virtualization. QW:247:SHARED.TEC --------------------------------------------------------------------------- Q24: How can I increase DESQview's performance? A24: DESQview's performance depends on many different factors. We will try to highlight some of the important areas here. DESQVIEW-OBLIVIOUS PROGRAMS Performance is especially degraded by DESQview-oblivious programs (see Q3), because they do not give up the CPU when they are not doing useful work (see Q9). Some programs, while waiting for keyboard input, continuously ask if a keystroke is available instead of giving up the CPU. Quarterdeck provides a way to force programs to give up the CPU after a specified number of keystroke queries. One of the bytes in the DVP file (the file edited by Change A Program) specifies the number of keyboard polls before the CPU is taken away. Unfortunately, Quarterdeck has never put a field on the Change A Program screens to change this number. DvpEdit, a freeware replacement for Change A Program, is available on SIMTEL20 (see Q7) and allows you to change this ``Max Keypolls'' value. Another well-known program is TAME. TAME does much more than watch for keyboard polling; and can do a good job of increasing performance. System performance can be measured with the PS utility available in the DVSI package (also on SIMTEL20 and DVNet). Using PS, an offending program can be quickly identified. DISK ACCESS Since disk access can slow down the system significantly (see Q10) using a disk cache can also increase performance. HyperDisk, available on SIMTEL20 (see Q7), is especially popular among DESQview users. FOREGROUND/BACKGROUND TICKS With the ``Tune Performance'' menu you can set the number of foreground and background ticks. These numbers indicate how much time DESQview is to allocate to a given task before moving on to the next in a round-robin fashion. The default setting is 9:3, which means DESQview gives the foreground task 9 ``ticks'', or roughly half a second, of CPU time, then gives each of the background tasks 3 ticks. A more common setting with today's hardware is 1:1 or 2:2 -- each task gets 1 (or 2) ticks. There's no single, optimal setting. Smaller numbers generally provide smoother performance, but may overwhelm the CPU on less powerful systems. In addition, time-sensitive applications like communications programs may need to be serviced frequently by the CPU. In short, experiment. Here's an undocumented trick: Go to ``Tune Performance'' and backspace to erase the numbers that are in the ticks fields. This will set them to ``H0'' (next time you bring up the ``Tune Performance'' window). This trick seems to set the ticks to 1/2 and 1/2 (although this claim has been disputed -- more experimentation will have to be done). Setting 0 background ticks will cause background windows to never run. Setting 0 foreground ticks will cause background windows to run only if the foreground window explicitly gives up its timeslice, or if it blocks (i.e. waits for a keystroke or other event). SCREEN DISPLAY There are three primary reasons why your screen may appear jerky. First, you may be virtualizing the window. While this prevents bleed-thru (when used in conjunction with QEMM-386), it does increase the workload on DESQview, and the screen output only occurs at the end of the program's timeslice. If this is a problem for you then configure your application to use BIOS screen writes and turn virtualization off. Second, you may need to adjust your tick settings. DESQview updates the screen display at the end of a task's CPU allocation. Thus, a setting of, say, 99:99 will result in extremely jerky screen updates compared with 2:2 or so. Third, you may be unnecessarily using NOFF.SHP (see Q23).